Integrated Circuit Design (ICD) or Chip Design is a branch of electronics engineering. The ICD deals with encompassing the particular logic and circuit design techniques required for designing Integrated Circuits (ICs). Initially, the ICs contained only a few transistors. However, the number of transistors in the ICs has increased dramatically since then. The term “Large Scale Integration” (LSI) was first used to describe this theoretical concept, which further gave rise to the terms including, but not limited to, a “Small-Scale Integration” (SSI), a “Medium-Scale Integration” (MSI), a “Very-Large-Scale Integration” (VLSI), and an “Ultra-Large-Scale Integration” (ULSI). The development of the VLSI started with hundreds of thousands of transistors in the early 1980s, and has continued beyond ten billion transistors as of now.
Modern ICs are immensely complicated. The complexity of the modern IC design and market pressure for producing designs rapidly has led to the extensive use of automated design tools in process of IC designing. In short, the design of an IC using an Electronic Design Automation (EDA) is the process of design, verification and testing of the instructions that the IC has to carry out.
The EDA and an Electronic Computer-Aided Design (ECAD) is a category of tools that is used to design electronic systems such as integrated circuits as well as printed circuit boards. Designers use these tools that work together in a flow to design and analyze the entire semiconductor chips. The EDA tools are essential for designing modern semiconductor chips which have billions of components. The EDA tools help chip design with programming languages that compiled them to silicon. Due to immediate result, there was a considerable increase in the complexity of the chips that could be designed, with improved access to design verification tools that are based on Logic Simulation. A chip designed using this process is easier to layout and more likely to function correctly, since the design of the chip could be simulated more thoroughly prior to construction. Although the languages and tools have evolved, this general approach of specifying the desired behaviour in a textual programming language and letting the tools derive the detailed physical design has remained the basis of digital IC design even today.
A Simulation (or “sim”) is an attempt to model a real-life or hypothetical situation on a computer to study the working of the system. Predictions may be made about the behaviour of a system, by changing variables in the simulation. It is a tool to virtually investigate the behaviour of the system under study.
A logic simulation is the use of simulation software for predicting the behaviour of digital circuits and Hardware Description Languages (HDL). It simulates the logic before it is built. Simulations have the advantage of providing a familiar look and feel to the user in that it is constructed from the same language and symbols used in design. Simulation is a natural way for the designer to get feedback on their design, by allowing the user to interact directly with the design. Logic simulation may be used as a part of a Functional Verification process in designing hardware.
Functional verification is the process followed for verifying whether the logic design conforms to the design specification. In everyday terms, the functional verification asserts whether the proposed design do what is intended. This is a complex task, and takes the majority of time and effort in largest electronic system design projects.
The HDL, a specialized computer language, is used for describing the structure and behaviour of electronic circuits, and most commonly, digital logic circuits. The HDL enables a precise, formal description of an electronic circuit which allows for the automated analysis and simulation of an electronic circuit. The HDL is much like a programming language such as C Programming language. The HDL is a textual description language consisting of expressions, statements and control structures. One important difference between most programming languages and the HDLs is that the HDLs explicitly include the notion of time. The key advantage of the HDL, when used for systems design, is that the HDL allows the behaviour of the required system to be described (modelled) and verified (simulated) before synthesis tools translate the design into a real hardware (gates and wires). With time, VHSIC Hardware Description Language (VHDL) and Verilog emerged as the dominant HDLs in the electronics industry, while older and less capable HDLs gradually disappeared. Over the years, much effort has been invested in improving HDLs. The latest iteration of the Verilog, formally known as System Verilog, introduces many new features (classes, random variables, and properties/assertions) to address the growing need for better testbench randomization, design hierarchy, and reuse.
A testbench is an (often virtual) environment used to verify the correctness or soundness of a design or a model. In the context of firmware or hardware engineering, a testbench refers to an environment in which the design/system/product under development is verified with the aid of software and hardware tools. The suite of verification tools is designed specifically for the design/system/product under verification. The testbench, commonly referred as a verification environment (or just environment) contains a set of components including, but not limited to, bus functional models (BFMs), bus monitors, memory modules, and interconnect of such components with a Design Under Verification (DUV).
A simulation environment is typically composed of several types of components. A generator generates input vectors that are used to search for anomalies that exist between an intent (specifications) and implementation (HDL Code). Modern generators create directed-random and random stimuli that are statistically driven to verify random parts of the design. The randomness is important to achieve a high distribution over the huge space of the available input stimuli. To this end, users of these generators intentionally under-specify the requirements for the generated tests. It is the role of the generator to randomly fill this gap. This allows the generator to create inputs that reveal bugs not being searched by the user. The generators also bias the stimuli towards design corner cases to further stress the logic. Biasing and randomness serve different goals and there are trade-offs between them. As a result, different generators have a different mix of these characteristics. Since the input for the design must be valid (legal) and many targets (such as biasing) should be maintained, many generators use the Constraint Satisfaction Problem (CSP) technique to solve the complex verification requirements. The legality of the design inputs and the biasing arsenal are modelled. The model-based generators use this model to produce the correct stimuli for the target design.
Drivers translate the stimuli produced by the generator into the actual inputs for the design under verification. The generators create inputs at a high level of abstraction, as transactions and drivers convert this input into actual design inputs as defined in the specification of the design's interface.
A Monitor converts the state of the design and its outputs to a transaction abstraction level so it can be stored in a scoreboard's database to be checked later on.
A Scoreboard/Checker validates that the contents of the scoreboard are legal. There are cases where the generator creates expected results, in addition to the inputs. In these cases, the checker must validate that the actual results match the expected ones.
An Arbitration Manager is configured to manage all the above components together.
The simulator produces the outputs of the design, based on the design's current state (the state of the flip-flops) and the injected inputs. The simulator has a description of the design net-list. This description is created by synthesizing the HDL to a low gate level net-list.
Simulation based verification is widely used to “simulate” the design, since this method scales up very easily. Stimulus is targeted to exercise each line in the HDL code. The testbench is built to functionally verify the design by providing meaningful scenarios to check that given certain input, the design performs to the specification.
The level of effort required to debug and then verify whether the design is proportional to the maturity of the design. That is, early in the design's life, bugs and incorrect behaviour are usually found quickly. As the design matures, the simulation requires more time and resources to run, and errors will take progressively longer to be found.
One of the most critical tasks in developing a new hardware such as the IC chips, Field-Programmable Gate Arrays (FPGA), Application-Specific Integrated Circuits (ASIC), System On Chips (SOC) etc. is to verify them for different design/function/performance specifications. These specifications may be predefined by the customer of the chips or can be an industry standard too. Another challenge faced by the verification team of this hardware is to debug the failures (if any) that arise during the process of verification using the log file(s) and identify the root cause of each failure.
Current verification trend uses the method of simulating the DUV/SUV against constrained random tests within a configurable verification environment and then evaluating the DUV/SUV's outputs against their corresponding predictions. It is to be noted that there may be multiple possibilities including, but not limited to, packet drops, packet routed to an unintended interface, packet ordering issues, and a broken DUV functionality that may cause an error or failure during the simulation. Most of the time, the flaws or errors in the DUV/SUV's design and some functionality failures might be uncovered and get reported during data integrity checks as data mismatches. It is important to note that as per conventional system and methodologies the investigation and understanding of the errors/failures is performed manually by a verification engineer. Thus, for a complex system, manual investigation/debugging of the errors/failures is a cumbersome and a time consuming process.